This application relates generally to a method for communication of dynamic vehicle diagnostic and telemetry data between a web-enabled transceiver connected to a vehicle data port and one or more computing devices, such as a desktop or laptop computer, network server, or hand-held device (which could be a smartphone, tablet, or some other device), and in particular to a method of providing motor vehicle data to one or more users using a heterogeneous group of user devices, while allowing each user to customize the data displayed on the user's device.
Since 1996, every passenger car and light-duty truck sold in the United States has had a computer diagnostic port, called an OBD-II port or an SAE-J1962 port. Most heavy-duty trucks currently sold in the United States also include a computer diagnostic port, usually referred to as a J1708 port or a J1939 port. This diagnostic port permits a mechanic or other user to connect to the vehicle and retrieve vehicle telemetry, that is, data about the vehicle, including engine, fuel system, brake system, and other data. Software has been developed to permit mechanics and automobile enthusiasts to develop graphical programs for displaying the diagnostic and telemetry data on a computer display.
Traditionally, vehicle data ports and diagnostic systems have been designed to permit a single external device (or “scan tool”) to connect to a vehicle at any one time. If a dashboard display device is already connected to the vehicle data port and a user wanted to plug in a separate scan tool, the user either had to unplug the dashboard display device, or somehow split the wires so that a second device can be connected. In fact, many companies currently sell vehicle data port splitters (or “Y-cables”).
In most cases, these types of arrangements are constructed so that multiple devices are physically connected to (or in electrical communication with) the vehicle data port, but typically only one device is actively communicating with the vehicle at any given time, while one or more other devices are in a monitor-only mode, without active bidirectional communication directly with the vehicle. This way, the vehicle maintains bidirectional communication with only a single device at a time. Often, that connected device has no knowledge that other external devices are also monitoring communications from the vehicle.
Using a splitter or “Y-cable” with more than one device concurrently communicating with vehicles today causes a number of problems. It is widely assumed that only one device will be communicating with the vehicle at once, and some vehicles even enforce this by only responding to data requests from a single address. In fact, newer vehicle data protocols have standardized on this practice by assigning external test equipment only a single allowable address range. If more than one device concurrently communicates with the vehicle, these protocols cause addressing conflicts, data collisions, timing violations and other kinds of related data acquisition problems.
In the past, multiple connected device usage has been mostly limited to the scan tool designers who occasionally want to connect a second device using a “Y-cable” to monitor the requests they transmit to verify conformance or to monitor and debug the scan tool communications. However, contrary to much of the prevailing wisdom in this area, the ability to have concurrent users all communicating with the same vehicle has definite advantages. Thus, development of such a system while staying compliant with existing vehicle protocols, which were typically not designed with multiple concurrent connections in mind, could be very useful.
Vehicle diagnostic scan tool hardware interfaces, or data port transceivers, typically utilize one or more of various communications protocols and/or connectivity systems such as USB, RS232, Ethernet, WiFi (Infrastructure, Adhoc, etc.), Bluetooth and others. Usually the communications protocol used depends upon the target computing device platform. For example, some computing device platforms may support WiFi but not USB, Bluetooth, or any others. Other computing device platforms may support Infrastructure WiFi and specific kinds of Bluetooth, but not Adhoc WiFi or any others. Because of this, the vehicle diagnostic hardware interface is usually sold as being compatible with specific computing device platforms, with various models available for various supported computing device platforms.
There are many computing device platforms currently in existence, such as Windows, Linux, Mac OS, iOS, Android, Blackberry, PalmOS, WebOS, Windows CE, Windows Phone, Symbian, QNX, Chrome OS, Tizen, Firefox OS, and many more. Developing a diagnostic scan tool software application (or “app”) separately for each computing device platform would be costly and time consuming. Most computing device platforms available today, especially for mobile computing devices, support WiFi and include a web browser application as well as embedded web clients and other web client support. Thus, development of a fully web-based diagnostic system that is compatible with a plurality of computing device platforms may be very useful.